feat: add external state provider implementation by meyer9 · Pull Request #197 · op-rs/op-reth

meyer9 · 2025-10-08T19:13:32Z

Based on #203 , #204

This PR implements StateProvider given a OpProofsStorage instance. It reads most data from the external database, but falls back on the latest provider for block hashes and code by hash similar to the existing historical provider in Reth.

This is an important part to implementing live syncing since we're running the sync process on the DB being created.

In the Reth implementation, proof.rs is contained in trie/db, so I think it makes sense to go in our DB crate. The provider.rs is in the reth-provider crate, but I don't think a separate provider crate helps us here, so I think we should also include that in the trie crate as well.

wiz-b4c72f16a4 · 2025-10-08T19:13:51Z

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	-

Total	-

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

Copilot

Pull Request Overview

Implements proof, root, and witness generation abstractions over OpProofsStorage, enabling trie-based state/account/storage proofs, roots, and witnesses sourced from an external (live-sync) storage backend while reusing existing Reth trie logic.

Adds OpProofs-backed cursor adapters and factories for trie and hashed views
Adds overlay_* helper trait extensions for Proof, StorageProof, StateRoot, StorageRoot, and TrieWitness to combine external DB data with in-memory post state / cached nodes
Exposes the new functionality via a new proof module

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
crates/optimism/trie/src/proof.rs	Introduces cursor wrappers, factories, and overlay trait implementations for proofs, roots, and witnesses over external storage.
crates/optimism/trie/src/lib.rs	Exposes the new proof module publicly.

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

Copilot · 2025-10-14T19:25:22Z

crates/optimism/trie/src/proof.rs

+        Self::from_tx(storage.clone(), block_number)
+            .with_trie_cursor_factory(InMemoryTrieCursorFactory::new(
+                OpProofsTrieCursorFactory::new(storage.clone(), block_number),
+                &nodes_sorted,
+            ))
+            .with_hashed_cursor_factory(HashedPostStateCursorFactory::new(
+                OpProofsHashedAccountCursorFactory::new(storage, block_number),
+                &state_sorted,


storage is cloned twice (lines 248 and 250) before the original is finally moved (line 254); you can reduce redundant cloning by introducing a single let storage_clone = storage.clone(); and reusing it (same pattern appears in overlay_multiproof at lines 270–273 and overlay_witness at lines 560–563).

Copilot · 2025-10-14T19:25:23Z

crates/optimism/trie/src/proof.rs

+            ),
+            address,
+            prefix_set,
+            // #[cfg(feature = "metrics")]


Leftover commented attribute (#[cfg(feature = "metrics")]) is dead code; remove it or reintroduce proper conditional compilation to avoid confusion.

Suggested change

// #[cfg(feature = "metrics")]

crates/optimism/trie/Cargo.toml

Based on #203 , #204 This PR implements `StateProvider` given a `OpProofsStorage` instance. It reads most data from the external database, but falls back on the latest provider for block hashes and code by hash similar to the existing historical provider in Reth. This is an important part to implementing live syncing since we're running the sync process on the DB being created. In the Reth implementation, `proof.rs` is contained in `trie/db`, so I think it makes sense to go in our DB crate. The `provider.rs` is in the `reth-provider` crate, but I don't think a separate provider crate helps us here, so I think we should also include that in the trie crate as well. --------- Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>